home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11366 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.6 KB  |  83 lines
  1. Path: chronicle.mti.sgi.com!news
  2. From: austern@isolde.mti.sgi.com (Matt Austern)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Will JAVA kill C++?
  5. Date: 14 Mar 1996 04:54:26 GMT
  6. Organization: SGI
  7. Message-ID: <AUSTERN.96Mar13205426@isolde.mti.sgi.com>
  8. References: <313E44EA.14D110C0@netcom.com> <4hp18v$3di@frodo.smartlink.net>
  9.     <4hqkfk$20j@galaxy.ucr.edu>
  10. Reply-To: austern@mti.sgi.com
  11. NNTP-Posting-Host: isolde.mti.sgi.com
  12. In-reply-to: thp@cs.ucr.edu's message of 9 Mar 1996 00:47:48 GMT
  13.  
  14. In article <4hqkfk$20j@galaxy.ucr.edu> thp@cs.ucr.edu (Tom Payne) writes:
  15.  
  16. > : In C++, or Fortran, or Eiffel, you can have an array of complex
  17. > : numbers.  In Java, though, you can't: you can have something that
  18. > : looks like an array of complex numbers, but internally it's really an
  19. > : array of pointers to complex numbers.  You have to pay a space penalty
  20. > : to store those pointers, and a time penalty to do the dereferencing on
  21. > : every element, and the optimizer will have to generate code on
  22. > : assumption that two array elements might point to the same object.
  23. > 
  24. > Are these references resettable?  If not, how can they be made to
  25. > collide like that?  In fact, if they are not resettable, is there
  26. > any reason that the extra level of indirection couldn't be 
  27. > optimized away?
  28.  
  29. public class complex
  30. {
  31.     public complex(double re, double im)
  32.     {
  33.     Re = re;
  34.     Im = im;
  35.     }
  36.  
  37.     public double Re;
  38.     public double Im;
  39. }
  40.  
  41.  
  42. class F
  43. {
  44.     static public void f()
  45.     {
  46.        complex[] A = new complex[3];
  47.        A[0] = new complex(1, 1);
  48.        A[1] = new complex(0, 1);
  49.        A[2] = A[0];    // A[0] and A[2] point to the same object.
  50.  
  51.        complex[] B = new complex[1];
  52.        B[0] = A[1];    // B[0] and A[1] now point to the same object.
  53.  
  54.        G.g(A);
  55.     }
  56. }
  57.  
  58. class G
  59. {
  60.     static public void g(complex[] array)
  61.     {
  62.         array[0].Re = 0;    // The compiler can't assume that array[0] is 
  63.                 //  the only element of array to have changed.
  64.     // ...
  65.     }
  66. }
  67.  
  68.  
  69. I don't see that Java solves any aliasing problems.  It does have
  70. pointers, and the fact of pointer semantics is very clearly visible to
  71. the user in many different ways.  I don't see how you could optimize
  72. away anything so fundamental and pervasive; if you're able to write an
  73. optimizer that can perform heroics like that, then dealing with the
  74. aliasing problems in C and C++ would be trivial.
  75.  
  76. Just to keep this slightly germane to C++, the right way to avoid
  77. aliasing problems is to use the valarray template.  You should ask
  78. your compiler vendor to implement valarrys, and to do it right.
  79. -- 
  80. Matt Austern
  81. SGI: MTI Compilers Group
  82. austern@isolde.mti.sgi.com
  83.